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ART-UNIT: 232 

PRIMARY-EXAMINER: Pan; Daniel H. 
ATT Y-AGENT- FIRM: Domingo; Richard B. 

ABSTRACT : 

A system for controlling use and distribution of digital works. The present 
invention allows the owner of a digital work to attach usaq^-T^qht^t o thei_r work . 
The usage rights define how the individual digit^^w^S^^^^^^^^^^^S^BM*^"^^ 

distributed. Instances of usa n^ ri o^^ are defined using a flexible and extensible 
usage rights grammar. Conce^uOT^^^^^right in the usage rights grammar is a label 
associated with a predetermined behavior and conditions to exercising the right. 
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The behavior of a usage right is embodied in a predetermined set of usage 
transactions steps. The usage transaction steps further check all conditions which 
must be satisfied before the right may be exercised. These usage transaction steps 
define a protocol for requesting the exercise of a right and the carrying out of a 
right . 

28 Claims, 20 Drawing figures 
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DOCUMENT-IDENTIFIER: US 5715403 A 

TITLE: System for controlling the distribution and use of digital works having 
attached usage rights where the usage rights are defined by a usage rights grammar 

Application Filing Date (1) : 
19941123 

Brief Summary Text (20) : 

U.S. Pat. No. 5,247,575, Sprague et al . , entitled "Information Distribution 
System", describes an information distribution system which provides and charges 
only for user selected information. A plurality of encrypted information packages 
(IPs) are provided at the user site, via high and/or low density storage media 
and/or by broadcast transmission. Some of the IPs may be of no interest to the 
user. The IPs of interest are selected by the user and are decrypted and stored 
locally. The IPs may be printed, displayed or even copied to other storage medias. 
The charges for the selected IP*s are accumulated within a user apparatus and 
periodically reported by telephone to a central accounting facility. The central 
accounting facility also issues keys to decrypt the IPs. The keys are changed 
periodically. If the central accounting facility has not issued a new key for a 
particular user station, the station is unable to retrieve information from the 
system when the key is changed. 

Brief Summary Text (21) : 

A system available from Wave Systems Corp. of Princeton, N.Y., provides for 
metering of software usage on a personal computer. The system is installed onto a 
computer and collects information on what software is in use, encrypts it and then 
transmits the information to a transaction center. From the transaction center, a 
bill is generated and sent to the user. The transaction center also maintains 
customer accounts so that licensing fees may be forwarded directly to the software 
providers. Software operating under this system must be modified so that usage can 
be accounted. 

Detailed Description Text (55) : 

FIG. 3 illustrates the repository 201 coupled to a credit server 301. The credit 
server 301 is a device which a ccum ulates billing inform a^Lion for the repository 
201. The credit server 301 corraR8f^^ate^^^ffi^repos^ory20^v^^Dilling 
transactions 302 to record billing transactions. Billing transactions are reported 
to a billing clearinghouse 303 by the credit server 301 on a periodic basis. The 
credit server 301 communicates to the billing clearinghouse 303 via clearinghouse 
transactions 304. The clearinghouse transactions 304 enable a secure and encrypted 
transmission of information to the billing clearinghouse 303. 

Detailed Description Text (58) : 

FIG^4^illustrates a printer as an example of a rendering system. Referring to 
^SS^St" 4, printer system 401 has contained thereirWa^pMJrffS^^^osWory 402 and a 
print device 403. It should be noted that the dashed line defining printer system 
401 defines a secure system boundary. Communications within the boundary is assumed 
to be secure. Depending on the security level, the boundary also represents a 
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barrier intended to provide physical integrity. The printer repository 402 is an 
instantiation of the rendering repository 205 of FIG. 2. The printer repository 402 
will in some instances contain an ephemeral copy of a digital work which remains 
until it is printed out by the print engine 403. In other instances, the printer 
repository 402 may contain digital works such as fonts, which will remain and can 
be billed based on use. This design assures that all communication lines between 
printers and printing devices are encrypted, unless they are within a physically 
secure boundary. This design feature eliminates a potential "fault" point through 
which the digital work could be improperly obtained. The printer device 403 
represents the printer components used to create the printed output. 

Detailed Description Text (64) : 

FIG. 5 illustrates the layout of a contents file. Referring to FIG. 5, a digital 
work 509 is comprised of story A 510, advertisement 511, story B 512 and story C 
513. It is assumed that the digital work is stored starting at a relative address 
of 0. Each of the parts of the digital work are stored linearly so that story A 510 
is stored at approximately addresses 0-30,000, advertisement 511 at addresses 
30,001-40,000, story B 512 at addresses 40,001-60,000 and story C 513 at addresses 
60,001-85K. The detail of story A 510 is illustrated in FIG. 6. Referring to FIG. 
6, the story A 510 is further broken down to show text 614 stored at address 0- 
1500, soldier photo 615 at addresses 1501-10,000, graphics 616 stored at addresses 
10,001-25,000 and sidebar 617 stored address 25,001-30,000. Note that the data in 
the contents file may be compressed (for saving storage) or encrypted (for 
security) . 

Detailed Description Text (86) : 

Communications integrity refers to the integrity of the communications channels 
between repositories. Roughly speaking, communications integrity means that 
repositories cannot be easily fooled by "telling them lies." Integrity in this case 
refers to the property that repositories will only communicate with other devices 
that are able to present proof that they are certified repositories, and 
furthermore, that the repositories monitor the communications to detect "impostors" 
and malicious or accidental interference. Thus the security measures involving 
encryption, exchange of digital certificates, and nonces described below are all 
security measures aimed at reliable communication in a world known to contain 
active adversaries . 

Detailed Description Text (90) : 

As a prerequisite to operation, a repository will require possession of an 
identification certificate. Identification certificates are encrypted to prevent 
forgery and are issued by a Master repository. A master repository plays the role 
of an authorization agent to enable repositories to receive digital works. 
Identification certificates must be updated on a periodic basis. Identification 
certificates are described in greater detail below with respect to the registration 
transaction . 

Detailed Description Text (92) : 

The hardware embodiment of a repository will be enclosed in a secure housing which 
if compromised, may cause the repository to be disabled. The basic components of 
the hardware embodiment of a repository are described with reference to FIG. 12. 
Referring to FIG. 12, a repository is comprised of a processing means 1200, storage 
system 1207, clock 1205 and external interface 1206. The processing means 1200 is 
comprised of a processor element 1201 and processor memory 1202. The processing 
means 1201 provides controller, repository transaction and usage rights transaction 
functions for the repository. Various functions in the operation of the repository 
such as decryption and/or decompression of digital works and transaction messages 
are also performed by the processing means 1200. The processor element 1201 may be 
a microprocessor or other suitable computing component. The processor memory 1202 
would typically be further comprised of Read Only Memories (ROM) and Random Access 
Memories (RAM) . Such memories would contain the software instructions utilized by 
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the processor element 1201 in performing the functions of the repository. 
Detailed Description Text (98) : 

The repository specific functionality 1304 comprises functionality that is unique 
to a repository. For example, the master repository has special functionality for 
issuing digital certificates and maintaining encryption keys. The repository 
specific functionality 1304 would include the user interface implementation for the 
repository. 

Detailed Description Text (110) : 

A credit server is a computational system that reliably authorizes and records 
these transactions so that fees are billed and paid. The credit server reports fees 
to a billing clearinghouse. The billing clearinghouse manages the financial 
transactions as they occur. As a result, bills may be generated and accounts 
reconciled. Preferably, the credit server would store the fee transactions and 
periodically communicate via a network with billing clearinghouse for 
reconciliation. In such an embodiment, communications with the billing 
clearinghouse would be encrypted for integrity and security reasons. In another 
embodiment, the credit server acts as a "debit card" where transactions occur in 
"real-time" against a user account. 

Detailed Description Text (221) : 

Transactions require that there be some communication between repositories. 
Communication between repositories occurs in units termed as messages. Because the 
communication line is assumed to be unsecure, all communications with repositories 
that are above the lowest security class are encrypted utilizing a public key 
encryption technique. Public key encryption is a well known technique in the 
encryption arts. The term key refers to a numeric code that is used with encryption 
and decryption algorithms. Keys come in pairs, where "writing keys" are used to 
encrypt data and "checking keys" are used to decrypt data. Both writing and 
checking keys may be public or private. Public keys are those that are distributed 
to others. Private keys are maintained in confidence. 

Detailed Description Text (222) : 

Key management and security is instrumental in the success of a public key 
encryption system. In the currently preferred embodiment, one or more master 
repositories maintain the keys and create the identification certificates used by 
the repositories. 

Detailed Description Text (223) : 

When a sending repository transmits a message to a receiving repository, the 
sending repository encrypts all of its data using the public writing key of the 
receiving repository. The sending repository includes its name, the name of the 
receiving repository, a session identifier such as a nonce (described below) , and a 
message counter in each message. 

Detailed Description Text (224) : 

In this way, the communication can only be read (to a high probability) by the 
receiving repository, which holds the private checking key for decryption . The 
auxiliary data is used to guard against various replay attacks to security. If 
messages ever arrive with the wrong counter or an old nonce, the repositories can 
assume that someone is interfering with communication and the transaction 
terminated . 

Detailed Description Text (225) : 

The respective public keys for the repositories to be used for encryption are 
obtained in the registration transaction described below. 

Detailed Description Text (228) : 

The registration transaction between two repositories is described with respect to 
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FIGS. 16 and 17. The steps described are from the perspective of a "repository-1" 
registering its identity with a "repository-2 " . The registration must be 
symmetrical so the same set of steps will be repeated for repository-2 registering 
its identity with repository-1 . Referring to FIG. 16, repository-1 first generates 
an encrypted registration identifier, step 1601 and then generates a registration 
message, step 1602. A registration message is comprised of an identifier of a 
master repository, the identification certificate for the repository-1 and an 
encrypted random registration identifier. The identification certificate is 
encrypted by the master repository in its private key and attests to the fact that 
the repository (here repository-1) is a bona fide repository. The identification 
certificate also contains a public key for the repository, the repository security 
level and a timestamp (indicating a time after which the certificate is no longer 
valid.) The registration identifier is a number generated by the repository for 
this registration. The registration identifier is unique to the session and is 
encrypted in repository-1 * s private key. The registration identifier is used to 
improve security of authentication by detecting certain kinds of communications 
based attacks. Repository-1 then transmits the registration message to repository- 
2, step 1603. 

Detailed Description Text (229) : 

Upon receiving the registration message, repository-2 determines if it has the 
needed public key for the master repository, step 1604. If repository-2 does not 
have the needed public key to decrypt the identification certificate, the 
registration transaction terminates in an error, step 1618. 

Detailed Description Text (230) : 

Assuming that repository-2 has the proper public key the identification certificate 
is decrypted, step 1605. Repository-2 saves the encrypted registration identifier, 
step 1606, and extracts the repository identifier, step 1607. The extracted 
repository identifier is checked against a "hotlist" of compromised document 
repositories, step 1608. In the currently preferred embodiment, each repository 
will contain "hotlists" of compromised repositories. If the repository is on the 
"hotlist", the registration transaction terminates in an error per step 1618. 
Repositories can be removed from the hotlist when their certificates expire, so 
that the list does not need to grow without bound. Also, by keeping a short list of 
hotlist certificates that it has previously received, a repository can avoid the 
work of actually going through the list. These lists would be encrypted by a master 
repository. A minor variation on the approach to improve efficiency would have the 
repositories first exchange lists of names of hotlist certificates, ultimately 
exchanging only those lists that they had not previously received. The "hotlists" 
are maintained and distributed by Master repositories. 

Detailed Description Text (232) : 

Assuming that the repository is not on the hotlist, the repository identification 
needs to be verified. In other words, repository-2 needs to validate that the 
repository on the other end is really repository-1. This is termed performance 
testing and is performed in order to avoid invalid access to the repository via a 
counterfeit repository replaying a recording of a prior session initiation between 
repository-1 and repository-2. Performance testing is initiated by repository-2 
generating a performance message, step 1609. The performance message consists of a 
nonce, the names of the respective repositories, the time and the registration 
identifier received from repository-1. A nonce is a generated message based on some 
random and variable information (e.g. the time or the temperature.) The nonce is 
used to check whether repository-1 can actually exhibit correct encrypting of a 
message using the private keys it claims to have, on a message that it has never 
seen before. The performance message is encrypted using the public key specified in 
the registration message of repository-1. The performance message is transmitted to 
repository-1, step 1610, where it is decrypted by repository-1 using its private 
key, step 1611. Repository-1 then checks to make sure that the names of the two 
repositories are correct, step 1612, that the time is accurate, step 1613 and that 
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the registration identifier corresponds to the one it sent, step 1614. If any of 
these tests fails, the transaction is terminated per step 1616. Assuming that the 
tests are passed, repository-1 transmits the nonce to repository-2 in the clear, 
step 1615. Repository-2 then compares the received nonce to the original nonce, 
step 1617. If they are not identical, the registration transaction terminates in an 
error per step 1618. If they are the same, the registration transaction has 
successfully completed. 

Detailed Description Text (233) : 

At this point, assuming that the transaction has not terminated, the repositories 
exchange messages containing session keys to be used in all communications during 
the session and synchronize their clocks. FIG. 17 illustrates the session 
information exchange and clock synchronization steps (again from the perspective of 
repository-1.) Referring to FIG. 17, repository-1 creates a session key pair, step 
1701. A first key is kept private and is used by repository-1 to encrypt messages. 
The second key is a public key used by repository-2 to decrypt messages. The second 
key is encrypted using the public key of repository-2, step 1702 and is sent to 
repository-2, step 1703. Upon receipt, repository-2 decrypts the second key, step 
1704. The second key is used to decrypt messages in subsequent communications. When 
each repository has completed this step, they are both convinced that the other 
repository is bona fide and that they are communicating with the original. Each 
repository has given the other a key to be used in decrypting further 
communications during the session. Since that key is itself transmitted in the 
public key of the receiving repository only it will be able to decrypt the key 
which is used to decrypt subsequent messages. 

Detailed Description Text (236) : 

A second session initiation transaction is a Login transaction. The Login 
transaction is used to check the authenticity of a user requesting a transaction. A 
Login transaction is particularly prudent for the authorization of financial 
transactions that will be charged to a credit server. The Login transaction 
involves an interaction between the user at a user interface and the credit server 
associated with a repository. The information exchanged here is a login string 
supplied by the repository/credit server to identify itself to the user, and a 
Personal Identification Number (PIN) provided by the user to identify himself to 
the credit server. In the event that the user is accessing a credit server on a 
repository different from the one on which the user interface resides, exchange of 
the information would be encrypted using the public and private keys of the 
respective repositories. 

Detailed Description Text (276) : 

There are variations known in the art which can be used to achieve the same effect. 
For example, the server could use an additional level of encryption when 
transmitting a work to a client. Only after the client sends a message 
acknowledging receipt does it send the key. The client then agrees to pay for the 
digital work. The point of this variation is that it provides a clear audit trail 
that the client received the work. For trusted systems, however, this variation 
adds a level of encryption for no real gain in accountability. 

Detailed Description Text (333) : 

A Backup transaction is a request to make a backup copy of a digital work, as a 
protection against media failure. In the context of repositories, secure backup 
copies differ from other copies in three ways: (1) they are made under the control 
of a Backup transaction rather than a Copy transaction, (2) they do not count as 
regular copies, and (3) they are not usable as regular copies. Generally, backup 
copies are encrypted . 

Detailed Description Text (335) : 

The output of a Backup operation is both an encrypted data file that contains the 
contents and description of a work, and a restoration file with an encryption key 
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for restoring the encrypted contents. In many cases, the encrypted data file would 
have rights for "printing" it to a disk outside of the protection system, relying 
just on its encryption for security. Such files could be stored anywhere that was 
physically safe and convenient. The restoration file would be held in the 
repository. This file is necessary for the restoration of a backup copy. It may 
have rights for transfer between repositories. 

Detailed Description Text (339) : 

The requester records the work contents, data, and usage rights. It then creates a 
one-time key an d encrypts the contents file. It saves the key information in a 
restoration file. 

Detailed Description Text (341) : 

In some cases, it is convenient to be able to archive the large, encrypted contents 
file to secure offline storage, such as a magneto-optical storage system or 
magnetic tape. This creation of a non-repository archive file is as secure as the 
encryption process. Such non-repository archive storage is considered a form of 
"printing" and is controlled by a print right with a specified "archive-printer." 
An archive-printer device is programmed to save the encrypted contents file (but 
not the description file) offline in such a way that it can be retrieved. 

Detailed Description Text (343) : 

A Restore transaction is a request to convert an encrypted backup copy of a digital 
work into a usable copy. A restore operation is intended to be used to compensate 
for catastrophic media failure. Like all usage rights, restoration rights can 
include fees and access tests including authorization checks. 

Detailed Description Text (347) : 

The server retrieves the key from the restoration file. It decrypts the work 
contents, data, and usage rights. 

Detailed Description Text (374) : 

The requester sends the server a message to initiate an Extract transaction. This 
message indicates the part of the work to be extracted, the version of the extract 
right to be used in the transaction, the destination address information for 
placing the part as a new work, the file data for the work, and the number of 
copies involved. 

Detailed Description Text (404) : 

The authorization server then "plays" the authorization. This involves decrypting 
it using either the public key of the master repository that issued the certificate 
or the session key from the repository that transmitted it. The authorization 
server then performs various tests. These tests vary according to the authorization 
server. They include such steps as checking issue and validity dates of the 
authorization and checking any hot-lists of known invalid authorizations. The 
authorization server may require carrying out any other transactions on the 
repository as well, such as checking directories, getting some person to supply a 
password, or playing some other digital work. It may also invoke some special 
process for checking information about locations or recent events. The "script" for 
such steps is contained within the authorization server. 

Detailed Description Text (411) : 

The requester decrypts the digital certificate using the public key of the master 
repository, recording the identity of the supplier and creator, a key for 
decrypting the software, the compatibility information, and a tamper-checking code. 
(This step certifies the software.) 

Detailed Description Text (412) : 

The requester decrypts the software using the key from the certificate and computes 
a check code on it using a 1-way hash function. If the check-code does not match 
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the tamper-checking code from the certificate, the installation transaction ends 
with an error. (This step assures that the contents of the software, including the 
various scripts, have not been tampered with. ) 

Detailed Description Text (422) : 

The requester decrypts the digital certificate using the public key of the master 
repository, recording the identity of the supplier and creator, a key for 
decrypting the software, the compatibility information, and a tamper-checking code. 
(This step authenticates the certification of the software, including the script 
for uninstalling it.) 

Detailed Description Text (423) : 

The requester decrypts the software using the key from the certificate and computes 
a check code on it using a 1-way hash function. If the check-code does not match 
the tamper-checking code from the certificate, the installation transaction ends 
with an error. (This step assures that the contents of the software, including the 
various scripts, have not been tampered with.) 

Detailed Description Text (447) : 

A customer buys and uses the work. He cannot make new copies because he lacks a 
distribution license. 



Detailed Description Text (449) : 

This is a variation on the previous scenarios. A ^di teiferi^i-bA i^feo^can sell to anyone and 
\J^^ZU anyone can s^^ L^^g^^^Pigjfl^^^^^^ ^^^ultinq in fees being paid back to the 

-^""creator. HowPv^^^^nTy license^^^s^^TOutors can add fees to be paid to themselves. 



Detailed Description Text (488) : 

The consumer goes to distributors and arranges to copy the work. The transaction 
offers the ticket. The distributor's repository punches the ticket and copies the 
new version to the consumers repository. 

Detailed Description Text (496) : 

This scenario is like the common practice of people making cassette tapes to play 
in their car. If a publisher permits the making of cassette tapes, there is nothing 
to prevent a consumer from further copying the tapes. However, since the tapes are 
"analog copies," there is a noticeable quality loss with subsequent generations. 
The new contribution of the present invention is the use of tickets in the access 
controls for the making of the analog copies . 

Detailed Description Text (512) : 

The information service bundles its database as files in a repository. The 
information services company assigns different fees for different rights on the 
information files. For example, there could be a fee for copying a search database 
or a source file and a different fee for printing. These fees would be in addition 
to fees assigned by the original creator for the services. The fees for using 
information would be different for using them on the information service company's 
computers or the client's computers. This billing distinction would be controlled 
by having different versions of the rights, where the version for use on the 
service company's computer requires a digital certificate held locally. Fees for 
copying or printing files would be handled in the usual way, by assigning fees to 
exercising those rights. The distinction between searching and viewing information 
would be made by having different "players" for the different functions. This 
distinction would be maintained on the client's computers as well as the service 
computers. Articles could be extracted for reuse under the control of Extract and 
Embed rights. Thus, if a client extracts part of an article or photograph, and then 
sells copies of a new digital work incorporating it, fees could automatically be 
collected both by the information service and earlier creators and distributors of 
the digital work. In this way, the information retrieval service could both offer a 
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wider selection of services and billing that more accurately reflects the client's 
use of the information. 

Detailed Description Text (543) : 

A signed digital message that attests to the identity of the possessor. Typically, 
digital certificates are encrypted in the private key of a well-known master 
repository. 

Detailed Description Text (546) : 
PUBLIC KEY ENCRYPTION : 

Detailed Description Text (547) : 

An encryption technique used for secure transmission of messages on a communication 
channel. Key pairs are used for the encryption and decryption of messages. 
Typically one key is referred to as the public key and the other is the private 
key. The keys are inverses of each other from the perspective of encryption . 
Restated, a digital work that is encrypted by one key in the pair can be decrypted 
only by the other. 

Detailed Description Paragraph Table (2) : 

TABLE 2 REPOSITORY SECURITY LEVELS Level 

Description of Security 0 Open system. 

Document transmission is unencrypted. No digital certificate is required for 
identification. The security of the system depends mostly on user honesty, since 
only modest knowledge may be needed to circumvent the security measures. The 
repository has no provisions for preventing unauthorized programs from running and 
accessing or copying files. The system does not prevent the use of removable storage 
and does not encrypt stored files. 1 Minimal security. Like the previous class 
except that stored files are minimally encrypted, including ones on removable 
storage. 2 Basic security. Like the previous class except that special tools and 
knowledge are required to compromise the programming, the contents of the 
repository, or the state of the clock. All digital communications are encrypted . A 
digital certificate is provided as identification. Medium level encryption is used. 
Repository identification number is unforgeable. 3 General security. Like the 
previous class plus the requirement of special tools are needed to compromise the 
physical integrity of the repository and that modest encryption is used on all 
transmissions. Password protection is required to use the local user interface. The 
digital clock system cannot be reset without authorization. No works would be 
stored on removable storage. When executing works as programs, it runs them in 
their own address space and does not give them direct access to any file storage or 
other memory containing system code or works. They can access works only through 
the transmission transaction protocol. 4 Like the previous class except that high 
level encryption is used on all communications. Sensors are used to record attempts 
at physical and electronic tampering. After such tampering, the repository will not 
perform other transactions until it has reported such tampering to a designated 
server. 5 Like the previous class except that if the physical or digital attempts 
at tampering exceed some preset thresholds that threaten the physical integrity of 
the repository or the integrity of digital and cryptographic barriers, then the 
repository will save only document description records of history but will erase or 
destroy any digital identifiers that could be misused if released to an 
unscrupulous party. It also modifies any certificates of authenticity to indicate 
that the physical system has been compromised. It also erases the contents 
of designated documents. 6 Like the previous class except that the repository will 
attempt wireless communication to report tampering and will employ noisy alarms. 10 
This would correspond to a very high level of security. This server would maintain 
constant communications to remote security systems reporting transactions, sensor 
readings, and attempts to circumvent security. 
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O'Conner, M.A., "New distribution option for electronic publishers; iOpener data 
encryption and metering system for CD-ROM use; Column," CD-ROM Professional, 
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TITLE: System for controlling the distribution and use of digital works having 
attached usage rights where the usage rights are defined by a usage rights grammar 

Detailed Description Text (232) : 

Assuming that the repository is not on the hotlist, the repository identification 
needs to be verified. In other words, repository-2 needs to validate that the 
repository on the other end is really repository-1 . This is termed performance 
testing and is performed in order to avoid invalid access to the repository via a 
counterfeit repository replaying a recording of a prior session initiation between 
repository-1 and repository-2. Performance testing is initiated by repository-2 
generating a performance message, step 1609, The performance message consists of a 
nonce, the names of the respective repositories, the time and the registration 
identifier received from repository-1. A nonce is a generated message based on some 
random and variable information {e.g. the time or the temperature.) The nonce is 
used to check whether repository-1 can actually exhibit correct encrypting of a 
message using the private keys it claims to have, on a message that it has never 
seen before. The performance message is encrypted using the public key specified in 
the registration message of repository-1. The performance message is transmitted to 
repository-1, step 1610, where it is decrypted by repository-1 using its private 
key, step 1611. Repository-1 then checks to make sure that the names of the two 
repositories are correct, step 1612, that the time is accurate, step 1613 and that 
the registration identifier corresponds to the one it sent, step 1614. If any of 
these tests fails, the transaction is terminated per step 1616. Assuming that the 
tests are passed, repository-1 transmits the nonce to repository-2 in the clear, 
step 1615. Repository-2 then <@@tTiTq7msRf:«tgfeewRe:®:ei^^ 

step 1617. If they are not identical, the registration transaction terminates in an 
error per step 1618. If they are the same, the registration transaction has 
successfully completed. 

Detailed Description Text (234) : 

After the session information is exchanged, the repositories must synchronize their 
clocks. Clock synchronization is used by the repositories to establish an agreed 
upon time base for the financial records of their mutual transactions. Referring 
back to FIG. 17, repository-2 initiates clock synchronization by generating a time 
stamp exchange message, step 1705, and transmits it to repository-1, step 1706. 
Upon receipt, repository-1 generates its own time stamp message, step 1707 and 
transmits it back to repository-2, step 1708. Repository-2 notes the current time, 
step 1709 and stores the time received from repository-1, step 1710. The current 
time is compared to the time received from repository-1, step 1711. The difference 
is then checked to see if it exceeds a predetermined tolerance (e.g. one minute), 
step 1712. If it does, repository-2 terminates the transaction as this may indicate 
tampering with the repository, step 1713. If not repository-2 computes an adjusted 
time delta, step 1714. The adjusted time delta is the difference between the clock 
time of repository-2 and the average of the times from repository-1 and repository- 
2. 

Detailed Description Text (412) : 
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The requester decrypts the software using the key from the certificate and computes 
a check code on it using a 1-way hash function. If the check-code does not match 
the tamper-checking code from the certificate, the installation transaction ends 
with an error. (This step assures that the contents of the software, including the 
various scripts, have not been tampered with.) 

Detailed Description Text (423) : 

The requester decrypts the software using the key from the certificate and computes 
a check code on it using a 1-way hash function. If the check-code does not match 
the tamper-checking code from the certificate, the installation transaction ends 
with an error. (This step assures that the contents of the software, including the 
various scripts, have not been tampered with.) 
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ART-UNIT: 2132 

PRIMARY-EXAMINER: Peeso; Thomas R. 
ATT Y-AGENT- FIRM: Staas & Halsey LLP 

ABSTRACT : 

An electronic data storage apparatus includes a data storage unit for storing 
electronic data; an authentication information generation unit for generating 
authentication information used in detecting an amendment made to the stored 
electronic data; and an authentication information data output unit for outputting 
the electronic data after adding to the electronic data the authentication 
information generated for the electronic data. When an authorization unit 
authorizes the electronic data storage apparatus after it is determined that the 
specification of the electronic data satisfies a predetermined condition, or when 
mutual authentication is performed between electronic data storage apparatuses, the 
electronic data storage apparatus stores the data. Thus, the electronic data can be 
protected from" being illegally amended or deleted, and can be safely stored in a 
format in which sufficient legal evidence can be maintained on the electronic data. 
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ART-UNIT: 362 

PRIMARY-EXAMINER: Gregory; Bernarr E. 

ATTY-AGENT-FIRM: Blakely, Sokoloff, Taylor & Zafman LLP 
ABSTRACT : 

A method and apparatus for encoding a purpose into a digital signature, where 
purpose and digital signature bound into an extended digital signature. The 
extended digital signature capability binds a purpose description identifying the 
purpose for the digital signature so that when affixed to a digital signature, the 
digital signature cannot be employed for improper purposes. A hash function is used 
to generate a hash value from the purpose description. The hash value is used in a 
digital signature function to bind the purpose to a digital signature. The extended 
digital signature can be verified for validity by comparing it to a hash value. In 
an electronic transaction, the extended digital signature can allow a purpose to be 
bound with the digital signature so that improper or unauthorized transactions are 
detected and disallowed. 

50 Claims, 9 Drawing figures 
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PRIMARY-EXAMINER: Swann; Tod R. 
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ATT Y- AGENT- FIRM: Antonelli, Terry, Stout & Kraus, LLP 
ABSTRACT : 

This invention provides a method for identifying a purchaser who purchased content 
from which an illegal copy was produced. A provider system encrypts a content 
purchased by the purchaser using a public key of a purchaser system and sends the 
encrypted content to the purchaser system. The purchaser system creates a digital 
signature of the content with the use of a private key of its own and embeds the 
created digital signature into the received content. When an illegal copy is found, 
the provider system verifies the digital signature, embedded in the illegal copy as 
a digital watermark, to identify the purchaser who purchased the content from which 
the illegal copy was produced. 

63 Claims, 29 Drawing figures 
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ABSTRACT : 

A method and apparatus for encoding a purpose into a digital signature, where 
purpose and digital signature bound into an extended digital signature. The 
extended digital signature capability binds a purpose description identifying the 
purpose for the digital signature so that when affixed to a digital signature, the 
digital signature cannot be employed for improper purposes. A hash function is used 
to generate a hash value from the purpose description. The hash value is used in a 
digital signature function to bind the purpose to a digital signature. The extended 
digital signature can be verified for validity by comparing it to a hash value. In 
an electronic transaction, the extended digital signature can allow a purpose to be 
bound with the digital signature so that improper or unauthorized transactions are 
detected and disallowed. 
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ART-UNIT: 362 
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ATTY-AGENT-FIRM: Bryan Cave LLP 

ABSTRACT : 

A method and system for selectively interconnecting a plurality of computers 
(112,114) over an open public network (120,102,122), such as the INTERNET, provides 
a private secure computer exchange of EDI interchange communications between a 
sender computer (112) and a recipient computer (114), each of which has an 
associated public key and an associated private key, such as in an RSA type 
cryptographic communication system (100) . The associated EDI acknowledgement 
message, such as the AUTACK, is used to provide secure authentication and non- 
repudiation of both origin and receipt of the secure private EDI interchange 
communications transmitted over the open public network (120,102,122) with the 
AUTACK transmitted from the sender computer (112) being digitally signed with the 
sender *s private key, and with the reply AUTACK transmitted from the recipient 
computer (114) being digitally signed with the recipient's private key. The 
respective digitally signed AUTACKs are decrypted after receipt by using the public 
key associated with the private key used to provide the digital signature. The 
transmitted AUTACK from the sender computer (112) includes an MD5 for the entire 
EDI interchange as well as an MD5 of the AUTACK, with the AUTACK, thus, being used 
to provide the digital signature. The reply AUTACK from the recipient computer 
(114) includes an MD5 of the reply AUTACK. The ability to conduct business over the 
network (120,102,122) is controlled by private trading partner agreement 
communications which provide key certification. 
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Previous Doc Next Doc Go to Doc# 



h eb bgeeefc ef 



e ge 



